Introducing Jenkins

Learn about Jenkins' power, popularity, scalability, and katas.

We'll cover the following

Brief history#

Jenkins began its life as Hudson, a build automation tool written in Java. While working at Sun Microsystems, Hudson was first developed in 2004 by Koshuke Kawaguchi. When Oracle bought Sun in 2009, a dispute over the Hudson name led its maintainers to rename the project to Jenkins. Open-source development of the CI system formerly known as Hudson continues under the Jenkins name. Jenkins went on to win awards as a Java application and as a CI tool.

Architecturally, Jenkins is fairly simple. Users of Jenkins create and maintain jobs or projects.

Project#

A project is a collection of steps, also called builds. The term “build” comes from Jenkins’ heritage as a build automation system. Building software typically refers to the process of compilation in which high-level, human-written code is translated into machine code.

Jenkins UI

A project is also often called a build; however, the steps in a project do much more than just compilation. Executing a project executes all the steps defined within it. Steps perform many different tasks, including:

  • Carry out SCM tasks that pull code from a repository
  • Update dependencies
  • Compile code
  • Run tests
  • Run scripts
  • Send notifications and alerts

Jenkins’ power and popularity#

Jenkins’ power and popularity stem from its core ability to run these and many more types of tasks. Jenkins is also extensible, with an API that allows developers to extend it with plugins. Independent developers and vendors have written hundreds of Jenkins plugins for a wide variety of custom tasks. This has made Jenkins easy to deploy into existing infrastructures and to integrate with many custom and vendor-produced systems.

Jenkins’ scalability#

Jenkins is also scalable. A Jenkins controller is the primary scheduler of jobs. Jenkins workers can run on other physical servers, virtual machines, or even in Docker containers. Large enterprises typically run a single controller (or a pair of controller, for redundancy) and many workers. Distributing jobs across workers provides scalability so that resources are always available when a build is started. Workers can also run on different operating systems, such as Windows or Linux, so that builds can be executed on the platform best suited to them. Jenkins jobs can be configured to run only on a defined subset of the workers available.

svg viewer

Jenkins for software development#

Software development teams use Jenkins to maintain visibility in their build pipeline. Failed builds can be configured to send alerts to the team so they can stop work and swarm the problem. This is another Agile and DevOps practice borrowed from Lean. It’s far more efficient to stop new feature development and fix the build than it is to defer the fix until later. Many development teams use large monitors placed in common spaces to display the status of all Jenkins jobs.

Jenkins katas#

The Jenkins katas will introduce us to building Jenkins jobs and demonstrate how Jenkins can be used to build, test, and deploy software. We’ll integrate Jenkins with a Git server and deliver a Docker container to a set of environments. Let’s jump in!

Continuous Integration

Quiz Yourself on Continuous Integration and Jenkins